Portals provide end users with unified access to content, applications, and collaboration services in a highly personalized manner. An example is IBM's WebSphere Portal which provides a middleware framework and tools for building and managing portals using component applications called “Portlets”.
Typically a Portal employs an architecture where the Portal itself only implements standard functionality like authentication, state handling, aggregation, caching, user management, and so on and provides the infrastructure for application components. This architecture includes APIs for the integration of applications so that applications from different partners can be used as long as they match the Portal product's API. In the Portal environment, these applications are typically called Portlets.
Portlets are pluggable components that can be added to Portals and are designed to run inside a Portal's Portlet container. Portlets may provide different functions ranging from simple rendering of static or dynamic content to application functions such as e-mail, calendar, etc. Portlets are invoked indirectly via the Portal application and produce content that is suited for aggregation in larger pages, e.g., Portlets should produce mark-up fragments adhering guidelines that assure that the content generated by different Portlets can be aggregated into one page. Typically, Portlets run on the Portal-Server, processing input data and rendering content locally.
FIG. 1A gives a schematic system view on a Web server implementing such prior art Portal.
A prior art Portal as e.g., represented by above IBM WebSphere Portal is built by a complex functionality implemented on a network server—for example a Web server 100, which has elements including logic components for user authentication 105, state handling 110, aggregation 115 of fragments, a plurality of Portlets 120—further described below—provided in respective pages 125 with a respective plurality of APIs 130 to a respective Portlet container software 135 for setting them into the common Web page context, and some Portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required. This is roughly depicted in FIG. 1A.
In more detail, a Portal engine of the Web server in FIG. 1A implements an aggregation of Portlets 120 based on the underlying Portal model 150 and Portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the Portal automatically generates the appropriate set of navigation elements based on the Portal model. The Portal engine invokes Portlets during the aggregation as required and when required and uses caching to reduce the number of requests made to Portlets. The prior art IBM WebSphere Portal employs open standards such as the Java Portlet API (application programming interface). It also supports the use of a remote Portlet via the WSRP standard.
The Portal model represents the Portal's content structure, i.e., the hierarchical structure of portal pages—which may again contain nested pages—and portlets, which are arranged on pages. This data is stored in the database 128 in an adequate representation based on prior art techniques like relational tables.
Web clients interact with portlets via a request/response paradigm implemented by the portal. Usually, users interact with content produced by portlets by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which are then forwarded to the portlets targeted by the user's interactions.
Accordingly, the Portal waits for client requests and responds to these requests. A client request message includes a URL/URI which addresses the requested page.
The before-mentioned aggregation logic includes all steps that are required to assemble a page that is sent back to the client. Typically, these steps are to load the Portal model from the Portal database, to traverse it and to call the instances referenced in the model in order to obtain their output, which is assembled to a single page. The Portal model may be defined as the relationship as well as the arrangement of the components that are used to create the visual representation of the content. The Portal model will be defined through the Manual Layout Interface 160 by the administrators or users and is saved in the database.
An activity in the rendering and aggregation processes is the generation of URLs that address Portal pages. A URL is generated by the Aggregation logic and includes coded state information.
By including the state information in a URL, the Portal ensures that it is later able to establish the navigation and presentation context when the client sends a request for this URL.
The Portlet container 135 is a single control component competent for all Portlets 120, which may control the execution of code residing in each of these Portlets. It provides the runtime environment for the Portlets and the facilities required for event handling, inter-Portlet messaging, and access to Portlet instance and configuration data, among others. The Portal resources 140 are in particular the Portlets 120 themselves and the pages 125, on which they are aggregated in form of an aggregation of fragments. A Portal database 128 stores the portlet description, this is in detail the portlet identifier, the portlet description featuring some attributes like portlet name, portlet description, portlet title, portlet short title, and keywords.
With special focus now at the present invention remote portlets are portlets, which reside on a different portal server and which are accessed through an appropriate web service protocol. The prior art Web Services for Remote Portlets (WSRP) specification defines a web service interface for accessing and interacting with portlets. In particular, WSRP allows a Portal to issue requests for remote portlets. WSRP supports: “Producers”, in the sense of WSRP or any other suited protocol supporting remote portlets that provide portlets as WSRP conformant web services; and, “Consumers” that use and invoke WSRP conformant web services, i.e., remote portlets.
A prior art WSRP Producer is a portal (see also FIG. 1A) that comprises a WSRP producer 190 and a SOAP server 180.
A WSRP Consumer (see FIG. 1B) is a portal which comprises a SOAP client 205 and a WSRP consumer 225.
The SOAP client 205 implements the functionality to invoke Web services over the SOAP protocol.
The WSRP consumer provides the functionality to invoke remote portlets over the WSRP protocol.
FIG. 1C illustrates the prior art interactions between a WSRP Consumer portal 100B and a WSRP Producer portal 100A.
Prior art WSRP Consumers allow to define so-called proxy portlets 225, which represent remote portlets on the consumer. The proxy portlet 226 is implemented by a portlet which adheres to the prior art portlet API. Instead of providing the functionality to process portlet requests, it implements functionality to invoke remote portlets through the WSRP consumer. By use of such type of proxy portlets 225 the advantage results that the other portlet components and in particular the portlet container do not need to be changed when they are required to support WSRP. The portlet container of the WSRP consumer portal shown in FIG. 1B invokes the proxy portlet 226 passing a portlet request. The proxy portlet invokes the WSRP consumer 225 to process the request. The WSRP consumer prepares the WSRP request message according to the passed portlet request and invokes the WSRP operation through the SOAP client 205. The SOAP client transfers the request message to the WSRP Producer portal 100A.
The SOAP server 180 implements the functionality to receive, process and to respond to SOAP requests. The SOAP server 180 is conFIGUREd to invoke the WSRP producer 190 when it receives a WSRP request (see left-to-right arrow in FIG. 1C). The WSRP producer accepts the WSRP request from the SOAP server and processes the request by preparing and invoking a respective request on its Portlet container 135. The portlet container processes the request by invoking the respective portlet, here a remote portlet 99 in view of the initial request, and returns the resulting response to the WSRP producer 190. From this response the WSRP producer creates the WSRP response and returns it to the SOAP server 180. The SOAP server finally returns the response to requester (see right-to-left arrow).
Next the aspects of Resource URL processing and Resource proxy functionality in prior art are described:
Prior art WSRP implementations realize so-called “resource URL” processing. As part of its markup, a Portlet will often need to create resource URLs that reference remote, non-portlet resources 98 such as JavaScripts, HTML documents, Servlets, Cascading Stylesheets, etc. It should be added that in contrast, another type of URL, namely so called portlet URLs, point to a portlet itself. Portlet URLs are not considered further in the context of the invention.
With additional reference to prior art FIG. 2, illustrating a sample interaction in a 3-tier system environment between a consumer portal 100B, a producer portal 100A and an end user client, when this End-User using a client Browser 26 activates a resource URL on the client by clicking a link or submitting a form, a new request issued to the network resource should result, step 210.
Typically a Producer not only offers the portlet but also provides the resources 98 that are referenced by the portlet 99.
In a 3-tier remote portlet scenario as depicted in FIG. 2, the end-user's client may not have access to the Producer portal 100A, for example because the Producer portal 100A is shielded from the client 26 via a firewall. In this case the networks are separated, and a URL generated by the Producer 100A cannot be invoked by the client.
Therefore prior art Consumer portals 100B incorporate a resource proxy component 200 (see FIG. 1B, 1C), which is able to accept a request for a resource issued by a client 26, to request the respective resource from the Producer 100A and to return the resource to the client 26.
In more detail, FIG. 2 shows a sample interaction between a consumer 100B and a producer 100A. Here a client 26 is assumed to request a portal page. In consequence the Consumer portal 100B invokes the WSRP getMarkup operation on the Producer in step 220. In detail, in step 220 the consumer invokes the getMarkup operation through its WSRP consumer 225 and its SOAP client 205 components which are not shown in FIG. 2, in order to improve clarity. The getMarkup response received in step 230 contains the markup generated by the remote portlet 99. The remote portlet 99 uses a special syntax to encode URLs. The WSRP consumer 225 of consumer portal 100B processes the portlet markup returned by the Producer portal 100A in order to rewrite URLs, step 240, comprising rewriting resource URLs, step 250. The WSRP Consumer detects resource URLs in the markup and modifies them, step 260, step 270, to point to the resource proxy and to include according context:
In more detail, the Consumer 225 of consumer portal 100B replaces a resource URL by a resource URL which is newly generated, step 270, wherein the newly generated one points to the resource proxy 200 and contains context information, that the resource proxy 200 in turn uses to locate and request the remote resource 98.
Finally the portal page is returned to the client, step 275.
When an end user activates the newly generated resource URL, the client Browser 26 sends a request to the resource proxy 200, step 280. The resource proxy 200 processes the context information contained in the URL, prepares the request by e.g. accessing a lookup table entering the client specified URL and looking up the producer portal-specific URL and sends a request to the resource, step 285. The resource proxy 200 accepts the data returned by the resource in step 290 and returns the data to the client in step 295.
The disadvantage of the above described prior art is, amongst others, that the consumer portal performs a resource URL rewriting independently of the underlying network structure. In particular, rewriting is done also in those cases in which it is not necessary, basically because a remote resource at the producer portal is directly reachable for a requesting client. Further, the URL rewriting process requires two different accesses to network resources, when the requesting end user client wants to access the remote resource. The first network access is the access to the resource proxy 200 described above, and the second network access is the actual access performed by this proxy portlet at the producer portal.
The objective of the present invention is to provide an improved access method for accessing remote network resources.